Yahoo! Groups have for a long time had big problems with allowing people to create obvious spam groups (randomly generated names, no meaningful description and so on) and then add people without any confirmation. This was annoying but at least they have an obvious abuse reporting link in the subscription mails. Sadly rather than improve the situation they appear to have just changed the link to not be a direct link to the reporting form but instead to be a generic help page. The link didn t change, the content just got even less useful. I m strongly tempted to just block all of Yahoo! from the mail systems I control.

Earlier today I gave a talk at Android Builders Summit about TinyHAL, a generic audio HAL for Android aimed providing a better basis for system integrators to work from. More details on TinyHAL and slides from the talk can be found over at the Wolfson Open Source web site.

Linux 3.2 was released yesterday. It s been a fairly busy release for ASoC in terms of the subsystem, including the first piece of work at moving the register I/O code over to regmap to eliminate the duplication there, but a pretty quiet one on the drivers front.

• Substantial optimization of the DAPM algorithm, substantially reducing the CPU usage when power states change. This is especially beneficial with larger modern devices.
• Support for CODEC drivers using the regmap API.
• Some smaller API updates support for larger register maps, support for specifying a source when setting a sysclk.
• New CPU drivers for Alchemy and Freescale MXS.
• New CODEC drivers for Analog ADAU1373, Realtek RT5631 and Wolfson Microelectronics WM1811 and WM5100.

Version 3.1 of the Linux kernel was the first release to include regmap support and only included a bare minimum of features in order to ease review so version 3.2 has been a pretty big one for regmap development with some pretty major features being built on top of the core code.

• Support for register caches Dimitris Papastamos ported his code for rbtree and LZO caches from ASoC over to regmap. This makes it easy for drivers to cache the current values of the device registers, improving performance by eliminating reads when doing read/modify/write cycles and providing functions to restore the register cache when resuming from power down. An indexed cache type was also added but this will be removed in 3.3 as it offers no real advantage over rbtree.
• Support for a wider range of SPI register transfer formats contributed by Lars-Peter Clausen.
• Tracepoints supporting both register access logging and monitoring of the time spent on register I/O operations.
• Register map dumps via debugfs to help provide diagnostic information during development.

Recently I ve been noticing a surprising pattern in code I m reviewing for the kernel. A lot of people seem to have taken to writing code that I d expect to look like this:

switch (thing)  
case VALUE:
        /* Stuff */
        break;
case BAR:
        /* Nonsense */
        break;
default:
        /* Whatever */
        break;
 

with if statements instead:

if (thing == VALUE)  
        /* Stuff */
  else if (thing == BAR)  
        /* Nonsense */
  else  
        /* Whatever */
 

(where stuff, nonsense and whatever are usually a bit larger). I really don t understand where this has come from the if based form isn t nearly so idiomatic for selecting between a range of values and this seems to have come from nowhere pretty much. Is there some code base out there where this is common practice or something?

A good proportion of I2C and SPI device drivers in the kernel contain some very similar code for accessing the register maps of hardware connected to those buses most hardware designers have solved the problem of providing very similar ways. Linux 3.1 introduces a new kernel API called regmap which factors out this code from the drivers, saving code and making it much easier to share infrastructure. There s been an implementation of this in ASoC for some time now, the regmap API makes it available to all drivers. The version of this API in version 3.1 is very simple, just factoring out the simplest level of physical I/O from the devices. Devices register with the regmap API by providing a struct regmap_config (which currently only allows the sizes of the register addresses and values to be specified) and the bus-specific structure to it. They can then use simple read and write operations on the device:

int regmap_read(struct regmap *map, unsigned int reg, unsigned int *val);
int regmap_write(struct regmap *map, unsigned int reg, unsigned int val);

The API handles everything to do with formatting the data for transmission and parsing data coming back from the device. Block functions are also provided to allow multiple registers to be read or written simultaneously. Even with this basic level of support we end up saving quite a bit of code as drivers are converted to use the API. The changes sitting in -next for version 3.2 take this a step further, adding support for more variations on SPI registers, a debugfs interface for dumping the device registers, register cache support courtesy of my colleague Dimitris Papastamos and trace points for dynamic instrumentation of the system.

Posted from Santa Rosa, California, United States.

One of the big things that seems to cause a learning curve for many new contributors for Linux and other projects that make a big effort with code review is the process of putting patches together in a way that makes the code review process more smoothly. This is a fairly straightforward thing but it takes a bit of getting used to for people who aren t used to the idea of patches and commits as a means of communication rather than just a mechanical thing you do to get changes into the codebase. In cases I ve seen the difficulty . I m mostly going to talk about this in the Linux context where patches are reviewed by e-mail but the same ideas apply if you re using a tool like gerrit to do the reviews; it s also mostly focused on detailed review rather than design level review. The basic idea is fairly simple the goal is to make it as easy as possible for someone to read and understand the change that s being made.

• Make sure the code matches the coding style of the code being modified.
• Make patches as small and self contained as possible having many patches is much easier than having complicated patches.
• Provide a changelog clearly describing everything that s going on in the patch.

The result here should be something that s easy for people to review. Keeping in line with the coding style is just a generally good idea for code legibility which is obviously a key thing for people reading the code to review it. Having a clear description of the change means that the reviewer knows what the patch is supposed to do and can verify that the patch does that rather than having to spend effort figuring out if whatever the code is doing is intentional. Making changes small and simple makes them much easier to think about the idea itself is easier to keep in your head and there s fewer things to check so the process of validating things is easier. It s not just about making life easier for reviewers. The process of making simple changes and describing them clearly can be really helpful for spotting issues when writing code; it forces you to think through what s being done much more clearly than might happen otherwise. There s also an ongoing benefit to anyone working with the code in the future. Since each change ends up including at least some explanation of what the code is supposed to do and since revision control systems generally have some equivalent of git annotate it s usually reasonably straightforward to find the changes that introduced the code that you re looking at. Small changes with good changelog entries mean it s much more likely that the changelog will provide a useful explanation as to what the author was thinking and explain why the code is the way that it is. It s much harder for documentation to go missing from the SCM than it is for it to go missing elsewhere, and it s much more likely that documentation in the commit is going to be up to date than external documentation, especially prewritten design documentation. In the context of large scale reviews the usual technique is to combine reviews of individual changes with a read through of the final code after all the individual changes have been applied. Often the build up of the code through incremental changes is a enough to show the overall design but a read through of the final code can be helpful in allowing people to understand where things are going.

Posted from Santa Rosa, California, United States.

One slightly unexpected effect of all the travel I ve been doing recently is that I get a real, visceral sense of place from some slightly surprising places when I see them on the big screen. Having an idea of how the place really is, how people behave, how the air feels, how the food tastes, how it smells, a sense of what s around the corner and beyond the camera. A sense of memory, not of imagination or of an idea of what a place should be. San Francisco is one place this happens for and is perhaps not so surprising it is a pretty distinctive place after all and the imagery was already familiar from countless movies and TV shows before I ever went there. What was a bit more surprising was a random suburban area in South Korea; Korea has had a real building boom amid all the growth it s had which has resulted in a certain look and feel to the architecture and the cities being very common though not distinctive of any once place. That s the space where a lot of the more real world Korean films are set, and it s the one I recognise. Don t think I ve ever seen a film that ventured into Itaewon ( ), mind you. It s a much stronger feeling of recognition than I get with anywhere in the UK, I think purely due to the surprise factor. Having a good picture of Edinburgh isn t a great surprise, finding how quickly I ve built one up of places on other continents much more so.

Linux 2.6.39 was released earlier today. This release includes a few updates, the main user visible one being that machine drivers can now be registered as regular devices rather than using the soc-audio device.

• Support for registering machine drivers as first class devices rather than using the soc-audio device. Support for the soc-audio device will be removed at some point in the future.
• Support for ordering widget power changes within widget types, helping with large CODECs and multi-stage amplifiers.
• Support for waiting for multiple slow events to complete during DAPM sequences, making it easier to handle things like DC offset correction on multiple outputs.
• CPU support for Intel Medfield and nVidia Tegra2.
• CODEC support for Cirrus CS4271, Freescale SGTL5000, Maxim MAX8950, National Semiconductors LM4857, TI SN95031 and Wolfson WM8991
• Machine support for Intel Medfield MID reference platforms, nVidia Harmony, and Visstrim M10.

There will be an ASoC conference in Edinburgh 4th-5th May this year, held in the Scotch Malt Whisky Society in Edinburgh. Full details are in the announcement if you ve got an interest in embedded audio on Linux I recommend you attend, there s a lot of development going on in this area right now and it promises to be a great opportunity to coordinate development plans and make sure things work well for everyone. Having met quite a few of the attendees who ve signed up already I can also say that it should be an opportunity to meet some really excellent people.

Linux 2.6.38 was just released, with another big update to ASoC including:

• Enhancements to multi-component from Jarkko Nikula allowing multiple devices of the same type to be included in one system (and handling other overlaps between devices) and support cross device DAPM.
• Support from Dimitris Papastamos for compressing the register cache in memory using either an rbtree or LZO, giving substantial memory savings on CODECs with large register maps, especially those that are sparse. This is especially beneficial to modern devices with integrated DSPs. This can be enabled by machine drivers, though CODECs can also provide defaults.
• Addition of trace points around DAPM and register I/O operation, allowing very low overhead logging without interfering with the main system log, useful for collecting verbose diagnostics without interfering with system operation and for always enabled flight recorder style tracking for intermittent problems. I blogged about ASoC trace points in more detail at the time.
• Restructuring of the Samsung CPU support from Jassi Brar, including a number of really good usability improvements. This supports features of more modern CPUs such as the ability to run two audio streams to a single I2S port and includes a number of API simplifications which should also make developing drivers for Samsung systems much easier.
• New CODEC drivers for ALC5621/2/3, WM8737, WM8770 and WM8958.
• Machine support for HP iPAQ H1940, HP t5325 thin clients and OpenRC Ultimate.

One of the biggest differences between working on most other OSs and working upstream on drivers for the Linux kernel is that elsewhere the core is usually a fixed thing that has been released and can t really be changed, even if source is available (which may not even be the case). If whatever subsystem you re working in can t cope with the thing you re trying to express then one of the things it s really useful to be good at is working out ways to implement the behaviour that s required behind the back of the subsystem. It s very common to see such code in drivers submitted by hardware vendors, particularly those that are new to Linux, as this is such a big mindset shift. With kernel development the approach is much more to make sure that the core can cope with whatever needs expressing. It s not always done in the core for example, sometimes the issue is due to unusually limited hardware and very likely to never come up again but it s very unusual to see code merged that doesn t at least fit in with the design of the subsystem. This post is inspired by a brief exchange with Thomas Gleixner on linux-kernel who articulated the advantages of doing things this way very well:

 - It's usually simpler and faster as the core code has all the
   necessary information. So that's even an argument which managers
   might understand.
 - Such workarounds, when not caught, tend to spread themself
   magically because driver writers checkout the existing code of
   similar devices and copy/paste/modify^Wuglify them over and over.
 - In the worst case such workarounds make the core maintainence
   harder and in some cases impossible, because they silently imply
   semantics on the core w/o the core maintainer knowing about them.

The last point is the most important one to me as a subsystem maintainer I really don t want to be merging code that is going to create issues with ongoing development of the subsystem. This is all another facet of the policy on stable APIs: APIs are only worth working around if they re fixed, and the assumptions that end up embedded in a workaroud are as much part of the API as the explicit interfaces. It s things like this that make Linux such a pleasure to work on.

Building the kernel for the Nexus S is straightforward the kernel is public as one would expect so it s simply a matter of building it using the standard Linux build system (the machine is called herring in the code). There is one gotcha, though the driver for the BCM4329 WiFi controller is a loadable kernel module rather than being built into the image. This means you need to copy it onto the device filesystem separately to flashing the kernel itself if you re only updating the kernel. The procedure I use for this is below it s straightforward but I m posting it here to make it a bit more discoverable. First we make the system partition writable:

adb root
adb remount

Then copy the BCM4329 driver over (the path to the driver here is running from the root of the kernel tree:

adb push drivers/net/wireless/bcm4329/bcm4329.ko /system/modules

Finally, reboot into the bootloader and flash the actual kernel:

adb reboot bootloader
fastboot flash zimage arch/arm/boot/zImage
fastboot reboot

Note that some of these commands may return before the operation they ve started has completed so you may need to wait for the phone at various points. As with updating the main system firmware the above requires an unlocked device which voids your warranty.

Kernel 2.6.38 will add support for tracing ASoC using trace points. Previously all logging for ASoC had been done using printk(), meaning that changing the active logging required a kernel rebuild and that when trace was enabled the volume of trace could easily become very disruptive to other logging within the system. Trace points solve these problems by providing a framework for enabling and disabling individual traces dynamically and separate logging infrastructure designed for easy filtering and post-processing. When using trace points it s reasonable to leave them enabled all the time, making life much easier especially when debugging intermittent problems. There s a bunch of existing documentation out there for the trace subsystem, including some in the kernel under Documentation/trace, which I won t repeat here. The ASoC events are grouped together under asoc . The raw log can be viewed by looking at the file tracing/trace in debugfs. Here s a sample output from starting playback of an MP3 on a Samsung SMDK6410 reference system using WM8580, a high performance six channel CODEC with a very simple software interface:

mplayer-1673  [000]   183.920000: snd_soc_dapm_start: card=SMDK-I2S
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Rear val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Center+Sub val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Front val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT3R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT3L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT2R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT2L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT1R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT1L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC3 val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC2 val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC1 val=1
mplayer-1673  [000]   183.920000: snd_soc_bias_level_start: card=SMDK-I2S val=2
mplayer-1673  [000]   183.920000: snd_soc_bias_level_done: card=SMDK-I2S val=2
mplayer-1673  [000]   183.920000: snd_soc_reg_read: codec=wm8580-codec.0-001b.27 reg=32 val=1e
mplayer-1673  [000]   183.920000: snd_soc_reg_write: codec=wm8580-codec.0-001b.27 reg=32 val=2
mplayer-1673  [000]   183.920000: snd_soc_bias_level_start: card=SMDK-I2S val=3
mplayer-1673  [000]   183.920000: snd_soc_bias_level_done: card=SMDK-I2S val=3
mplayer-1673  [000]   183.920000: snd_soc_dapm_done: card=SMDK-I2S
mplayer-1673  [000]   183.920000: snd_soc_reg_read: codec=wm8580-codec.0-001b.27 reg=13 val=10
mplayer-1673  [000]   183.920000: snd_soc_reg_write: codec=wm8580-codec.0-001b.27 reg=13 val=0

Each line represents a trace event, showing the process that initiated the event, the CPU it ran on and the time it was recorded at together with event-specific details. On this system the time is reported with 10ms accuracy and the CODEC is very simple so the timing information is not terribly informative, but more accurate timers can be really helpful in analysing what s going on with more complex CODECs. The set of events available will change over time, the key ones currently present in the kernel are:

• snd_soc_dapm_start and snd_soc_dapm_done: These events show the start and stop of the DAPM algorithms, showing the time spent on power management decisions.
• snd_soc_dapm_widget_power events are generated for each of the widgets which DAPM has determined needs to change state. The val=1 means that all these widgets are being powered up, val=0 would show power down.
• snd_soc_reg_write events show values written to registers.
• snd_soc_reg_read events show values read from registers these reads may be done from the register cache, or may be from the hardware.
• snd_soc_dapm_widget_event_start and snd_soc_dapm_widget_event_done show the time spent in per-widget event callbacks.

The set of events traced will change as the subsystem develops and as people gain more experience with using the trace API.

2.6.37, which was released today, has been a very big release for ASoC about 40,000 lines of changes covering every single file within the subsystem plus a bunch of new drivers. The highlights are:

• Overhaul of the core APIs for registration of all kinds of devices from my co-maintainer Liam Girdwood, reducing the level of direct coupling between machine drivers and their CODEC and CPU drivers allowing ASoC machines to have multiple CODEC devices and multiple instances of the same CODEC device within a system.
• New CODEC drivers for 88PM860x CODEC, MAX98088/9, WL1273, WM8962, WM8804, and WM8985.
• New CPU drivers for EP93xx AC 97 controllers, MPC 85xx SSI ports, and SH HDMI controllers.
• Machine support for Freescale P1022 DS, Marvell Tavor and Saarb and Simplemachines Sim.One

Since I couldn t seem to readily find any useful instructions for building firmware images for the Nexus S I thought I d publish some. In a clean directory this sequence of commands should result in a working set of application layer images. They assume you ve already got all the Android build dependencies installed:

repo init -u git://android.git.kernel.org/platform/manifest.git -b gingerbread
repo sync
MYDROID=$(pwd)
export MYDROID
. ./build/envsetup.sh
make PRODUCT-full_crespo-user

The resulting images will be in the directory out/target/product/crespo. You can get this running on your device by flashing the boot, recovery and system images:

out/host/linux-x86/bin/fastboot flash boot out/target/product/crespo/boot.img
out/host/linux-x86/bin/fastboot flash recovery out/target/product/crespo/recovery.img
out/host/linux-x86/bin/fastboot flash system out/target/product/crespo/system.img

Note that using these firmware images will void any warranty you have on the phone you ll need to unlock the phone using fastboot oem unlock, but note that this is irreversible. Similar instructions should work for Nexus One too, using passion instead of crespo in the make command above.

Linux 2.6.36 was released today. This has been a very quiet release for the ASoC core code but one of the busiest releases for a while for new CPU support, with four new architectures added:

• CODEC support for JZ4740, WM8741, and WM8987
• CPU drivers for EP93xx, JZ4740, Marvell Kirkwood/Orion I2S, NUC900, and SH S/PDIF
• Machine support for Eureka, OpenRD, qi_lb60, SmartQ, and Snapper CL15

Recently I ve been using ebook readers rather a lot mostly the Kindle DX, though I have given iBooks a spin as well. Obviously, as with MP3 players, the main win they offer is the ability to easily carry about an entire library without the inconvenience of the physical media. I ve been reading an awful lot more than before since I started using them, mostly by virtue of it being very easy to keep several books on the go at once. What I ve found especially good with the Kindle is the ease with which I can flip between devices, taking advantage of the tradeoffs between the different form factors. Phones are obviously portable and these days have clear, easy to read screens (in most lights anyway) and are very light and easy to hold. They re great if you re stuck in a queue or on a bus but the small screen size and the fact that keeping the screen on for an extended period of time runs down the battery which isn t always desirable. Computers are similar, trading off portability and convenience in the form factor for the larger form factor. The iPad deals with the screen size issue without much impact on either the form factor or the battery life but the LCD display is hard to read in sunlight and can be hard on the eyes for extended use. E-Ink displays deal with those issues by swapping them for others that mean they can only work for eBooks so the devices aren t at all general purpose. The first generation of displays had problems with frustratingly long refresh times and less than ideal contrast ratios but these have been largely addressed in current generations of device current generation displays are beautiful. Thus far I ve pretty much just been reading copies of books I already have physical copies of so I ve not really had a think about how I feel about any of the models for eBook publishing that are floating about out there, or about the DRM issues.

A discussion the other night suggested that I m quite unusual among geeks in doing vanishingly little customisation of my system most of my systems have something very close to their default configuration, individual programs are usually at most a very few tweaks away from their upstream settings. For Emacs all I tend to do is install revbufs, set Linux mode by default for C and turn on syntax highlighting and line number mode (sometimes the last two only get done when I start Emacs). For vim it s just configuring a 72 column word wrap if my main use for vi on the system will be writing e-mail. For GNOME it s putting a terminal launcher in one of the panels and setting focus follows mouse. All very trivial stuff done in five minutes. The theory here is partly that I just can t be bothered to spend more time on tweaking things (and the subsequent carrying around of those tweaks) and partly that it ensures that I m not confused when I end up using a new system or someone else s for whatever reason. I find it somewhat odd that this would be something you d want to spend any time on.

Linux 2.6.35 has been a fairly interesting release from an ASoC point of view, with several notable framework enhancements:

• Support for keeping audio paths through the CODEC up during system suspend, primarily intended for use with devices where the Linux system is one of several independent systems running on the device and the other systems (like the cellular modem in a phone) can maintain useful audio paths even when the Linux system is inactive.
• Enhancements to the jack detection infrastructure, including the addition of notifiers on jack status changes (allowing better integration of physical jack detection with electronic methods) and snd_soc_dapm_force_enable_pin() (which allows DAPM managed supplies such as microphone biases to be forced on). For example, jack status change notifications can be used to enable microphone detection via bias current sense only when a microphone is physically present.
• Support for knot and continuous PCM rates in the core.
• SMDK6410 5.1 audio support, TI SDP4030 audio support, and basic support for playback on the 1133-EV1 PMIC module for Freescale i.MX31ADS systems (currently limited by the support for the SSI interface on the i.MX31).
• Support for DaVinci integrated voice CODECs, Philips UDA1345 CODEC, SuperH FSI2 interfaces, TI OMAP4, TWL6040 CODECs, WM9090 audio subsystem.